The related "An Object Oriented Framework Mechanism Providing Common Object Relationship and Context Management for Multiple Tools", U.S. application Ser. No. 08/950,117, relates to a framework mechanism for tool data management. The locking mechanism of the present invention can be used in such an environment.
Tools are units of software, programs or application modules within programs, that store, manage and retrieve data for the user. Every new tool under development includes work to design, implement and test the storage mechanisms for the tool data. As a result, the costs associated with new tool development (both in time and money) are generally not insignificant.
Most tools have their own mechanisms for storing and managing data which is often "proprietary". In this context, proprietary means that details of the implementation are not shared with other tool manufacturers or developers. This leads to a number of problems associated with customizing and extending existing, proven tools to meet individual user needs. For example, the interface or "view" portion of a tool may be intertwined with a storage mechanism or model of a tool, leading to difficulties in integrating new views with existing ones. This is referred to as a lack of neutrality in the tool.
Also, data produced by one tool cannot be consumed directly or transparently by another tool. Instead, operations such as "export", which writes data to a foreign format consistent with other tools, and "import", which reads data of a foreign format, are required, and the user of a tool must consciously choose to export or import data between tools.
In addition, portions of data imported from a foreign format may be meaningless to or incompatible with the data store of the importing tool and summarily discarded. This sacrifices round trip integrity of the information, and iterative development of information in more than one tool becomes difficult or impossible.
Finally, tool developers must monitor revisions to or the invention of other tools that manage similar data, and add new function to export and import the corresponding new data formats. In addition to the raw expense of developing and testing new import and export functions, there is the time lag between the introduction of a new format and the availability of import and export fuinctions in other tools to handle the format.
Object oriented (OO) programming, and in particular OO framework technology, provide a way to address the cost associated with constantly reworking existing tools and provide data integrity in the use of multiple tools.
Object Oriented Technology v. Procedural Technology
Though the present invention relates to a particular OO technology (i.e., OO framework technology), the reader must first understand that in general, OO technology is significantly different then conventional, process-based technology (often called procedural technology). Both technologies can be used to solve the same problem, but the ultimate solutions to the problems are always quite different. This difference stems from the fact that the design focus of procedural technology is wholly different than that of OO technology. The focus of process based design is on the overall process that solves the problem. By contrast, the focus of OO design is on how the problem can be broken down into a set of autonomous entities that can work together to provide a solution. The autonomous entities of OO technology are called objects. In other words, OO technology is significantly different from procedural technology because problems are broken down into sets of cooperating objects instead of into hierarchies of nested computer programs or procedures.
A significant feature of OO programming is that the objects are reusable software entities that can be combined in different combinations or ascribed different attributes for different uses. An example of this is found in U.S. Pat. No. 5,550,971 for Method And System For Generating A User Interface Adaptable To Various Database Management Systems, of U.S. West Technologies, Inc., which describes a dynamic model for generating a user interface with various "information forms" illustrating a data base schema. The model is transportable to different data base management systems without the user having to learn different query languages, data base systems and specific data base records, fields and relationships. The model is implemented by a set of concrete classes whose instances represent entities and relationships at various distances from an actual data base. Objects of these classes are created and interrelated to describe the organization of a data base. The model classes provide standard interfaces for exploring the structure of an actual data base to create a user interface and for caching data base information consumed by the user interface.
Along similar lines is U.S. Pat. No. 5,428,729 for System And Method For Computer Aided Software Engineering, of IBM Corporation, which describes a system designed to track the location of and access to data entities (documentation, source code, test data), and to reference procedures for the translation of data (compilers, editors, linkers, documentation formatters, test harnesses) within the context of a software project under development. Each new project under development is created from a template by the "metaprogrammer" and is presented via a GUI (graphical user interface). From this "master view", each user can clone a "user view" consisting of a subset of objects from the master selected according to the access rights of the user. Through a view, specific flows are described wherein a user can access data entities to edit, define and dispatch build procedures, and define and dispatch test cases. Access rights relate users to objects via "classes" of users. This patent is oriented around the appearance and flow of a GUI and how it provides access to files stored in arbitrary but distinct repositories, stores rules for translating files from source to target form, and controls access via user-specific views of a project. However, this is not an object oriented data integration framework, and a fundamental difference between this system and the present invention is that the patented system is not designed to promote consistent behavioural feel amongst multiple distinct and unknown tools through specified but extensible framework interfaces and protocols.
Terms and phrases have evolved in the art which have particular meaning to those skilled in the art of OO design. However, the word "framework" is one of the most loosely defined; it means different things to different people. Therefore when comparing the characteristics of two supposed framework mechanisms, care should be taken to ensure that the comparison is appropriate.
As described more specifically below, the term "framework" is used in this application to describe an OO mechanism that has been designed to have core function and extendable function. The core function is that part of the framework mechanism that is not subject to modification by the framework purchaser. The extensible function, on the other hand, is that part of the framework mechanism that has been explicitly designed to be customized and extended by the framework purchaser.
OO Framework Mechanisms
An OO framework mechanism can generally be characterized as an OO solution. Nevertheless there is a fundamental difference between a framework mechanism and a basic OO solution Framework mechanisms are designed in a way that permits and promotes customization and extension of certain aspects of the solution. In other words, framework mechanisms amount to more than just a solution to the problem. The mechanisms provide a "living" solution that can be customized and extended to address individualized requirements that change over time. As discussed in the background portion above, the custontization/extension of quality of framework mechanisms is extremely valuable to purchasers because the cost of customizing or extending a framework is much less than the cost of replacing or reworking an existing non-framework solution.
Therefore, when framework designers set out to solve a particular problem, they do more than merely design individual objects and how those object interrelate. They also design the core function of the framework (ie, that part of the framework that is not to be subject to potential customization and extension by the framework consumer) and the extensible function of the framework (ie, that part of the framework that is to be subject to potential customization and extension). In the end, the ultimate worth of a framework mechanism rests not only upon the quality of the object design, but also on the design choices involving which aspects of the framework represent core functions and which aspects represent extensible functions.
An example of a framework is the subject of U.S. Pat. No. 5,325,533 for Engineering System For Modelling Computer Programs, of Taligent, Inc. The framework described in this patent provides incremental interaction, generation and build facilities for a development environment.